TeamTNT di nuovo all’opera, dopo Docker punta ai server AWS
Trendmicro smaschera per una seconda volta l’organizzazione criminale TeamTNT.
Il report pubblicato dalla società di sicurezza, conferma di aver trovato una seconda versione della botnet, più potente e raffinata. Se una prima versione del malware colpiva solo Docker ora è in grado di colpire anche i server di AWS.
Gli sviluppatori TeamTNT non sono più interessati solo al mining, ma ora gli script dannosi vengono sviluppati per rubare dati come credenziali e password. Inoltre la nuova versione del botnet è in grado di preparare l’ambiente per assicurarsi che abbia risorse sufficienti per minare la sicurezza di altre piattaforme, in effetti si nascondono nel sistema e installano anche backdoor nel caso in cui debbano connettersi da remoto ai server infetti.
Cosa succede? TeamTNT accede ai container Docker esposti, installando un malware di cripot mining, e ruba le credenziali per i server di AWS al fine di pivot su altri sistemi IT di un’azienda per infettare ancora di più server e distribuire miner di criptovalute. Questo tipo di attacco è pericoloso per le aziende che sono esposte online e anche per quelle che utilizzano API di gestione Docker. A questo punto una domanda sorge spontanea, è davvero possibile subire un simile attacco? Come è possibile lasciare spazio e dare libero accesso ai container?
La risposta è legata ad una delle seguenti alternative:
- Bug dell’applicativo, o di altri pezzi software contenuti nel container;
- API di Docker esposte a tutti;
- Repository Git non protetti, o protetti male (credenziali finite pubbliche, ecc.);
- Eventuali DB usati dall’applicativo esposti su internet.
Per non cadere nell’errore ed evitare che di esporsi a rischi di questo tipo, abbiamo stilato una lista di Best Practices da mettere in atto per proteggere i clienti da un eventuale attacco malware:
- Utilizzo di IAM Roles invece di utilizzare chiavi programmatiche come Access Key e Secret Access per le chiamate autenticate a servizi AWS
- Organizzazione networking con subnet pubbliche/private per proteggere i nodi “master” se utilizzato EKS o non esporre le EC2 in caso di ECS su EC2
- Avere un unico punto di accesso all’infrastruttura (come CDN) che sarà protetto poi con Web Application Firewall (WAF) per evitare attacchi di tipo DDoS, XSS, SQL Injection (protezione a livello 7 pila ISO/OSI) e protezione a livello 3-4.
- Utilizzo sempre di repository private (Code Commit/git/ecr)
- Non esporre credenziali applicative nei repository ma con altre soluzioni, come Bucket S3 locked da policy stringenti, AWS System Manager.
Inoltre bisogna ricordare che tutte le chiamate a servizi AWS richiedono un’autenticazione, anche via API e che AWS di default non espone nulla su internet.
Ecco due casi studio reali sui quali VMEngine è riuscita a impostare al meglio tutte le policy di sicurezza andando ad incidere positivamente sulle prestazioni e rendendo l’architettura IT protetta e scalabile:
